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ABSTRACT 


This report deals with Shuttle simulation software modules In the 
Environment, Crew Station, Vehicle Configuration and Vehicle Dynamics 
categories. 

For each software module covered, this report provides a description 
of the module functions and operational modes, its interfaces with other 
modules, its stored data, inputs, performance parameters and critical 
performance parameters. 

Reference data sources which provide standards of performance 
are identified for each module. Performance verification (validation) 
methods are also discussed briefly. Detailed treatment of performance 
verification techniques is deferred to a later report. 
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SECTION 1 
INTRODUCTION 

This report covers a portion of the work done under WBS 2.0 
of the Simulation Verification Techniques Study. 

1.1 PURPOSE 

li;o purpose of WBS 2.0 is to develop methods for verifying 
simulation fidelity with respect to the real world; i. e.» to ensure 
that the simulator responses presented to the crew are indiscernible 
from those which will be experienced during actual flight. During 
simulator development, performance verification(validation)is performed 
on individual software modules, at various stages of integration, and 
finally for the all-up simulator system. In addition, revalidation will 
be necessary from time to time during a simulator's operational lifetime, 
as modifications are made to hardware and/or software. 

WBS 2.0 is divided into three subtasks: 

• WBS 2.1, Definition of Performance Parameters: Analyze each Shuttle 
subsystem and simulation module; define a set of parameters which 
completely describe each subsystem/module. 

• WBS 2.2, Establishing Standards of Performance: Define methods to 

provide reference data to serve as standards of performance for 
module validation (e.g., batch programs, test data). 

Define data formats, determine database impact. 

• WBS 2.3, Methods for Validating Performance: Define methods for 

realtime performance data acquisition and comparison with reference 
data; define comparison criteria. 
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1.2 SCOPE OF THIS REPORT 

Each of these subtask efforts must be applied in the context of 
each subsystem/module, as well as in the context of integrated simulator 
system operation. Because of the considerable body of specialized 
Information required, it is convenient to work on the performance 
parameter identification, reference data sources and validation methods 

peculiar to a module all at once, rather than dealing with different 
aspects of a particular module at three widely-separated times. For 
that reason, this report Is organized on the basis of the simulation 
software module hierarchy, and includes module-oriented efforts which 
fall under all three WBS subtasks. 

Figure 1-1 shows an overview of the simulation software module 
hierarchy developed for use In WBS 2.0. The software categories covered 
in this report -- Environment, Crew Station, Vehicle Configuration, and 
Vehicle Dynamics — are enclosed in dotted lines. 

For each module covered, this report provides a description of the 
module's functions and operational modes, its stored data and inputs, and 
its performance parameters (including "critical" performance parameters as 
defined below). Sources of reference (standards) data are Identified, and 
performance- verification techniques and support software are briefly 
discussed. 

Later reports will complete our coverage of the software module 
hierarchy, and deal in depth with reference data sources, data formatting, 
database impact, and performance verification techniques and support 
software. 
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SECTION 2 

MODULE PERFORMANCE PARAMETERS AND STANDARDS OF PERFORMANCE 

2.1 GENERAL 

Several topics of general applicability to all modules are 
treated here, to unify subsequent discussion of individual modules. 

2.1.1 Performance Parameter Guidelines 

In performing an analysis of each onboard subsystem and simulation 
software module, we must extract from the basic defining information a 
list of performance parameters, which completely describes the performance 
of the subsystem/module. By this we mean that any error or inadequacy 
in the simulation must show up in one or more of the designated performance 
parameters. We envision such a complete performance parameter list to be 
useful primarily in the exhaustive initial validation of the simulator. 

In addition, we have further examined the complete parameter list for 
each module, designating a subset thereof as "critical" performance parameters. 
The primary utility of the critical parameter list would be in revalidating 
simulation modules after modifications or updates, the presumption being 
that, if a module's critical parameters provide acceptable fidelity, it will 
not be necessary to check the rest of the performance parameters. Criteria 
for identification of performance parameters and critical performance 
parameters are given below. 

2. 1.1.1 Performance Parameters 

The performance parameters for any onboard subsystem (simulation module) 
or for the total system (total simulation) must have the following properties: 

a. They must be real-world variables (either continuous or discrete). 
Thus, synthetic variables which are defined for analysis and pro- 
gramming purposes -- e.g., auxiliary angles, counters, initializa- 
tion flags — cannot be performance parameters. 

b. They must be time-variable quantities, not constants; e.g., 
aerodynamic-coefficient tables are not performance parameters. 

c. All system "state variables" are performance parameters. (State 
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variables may be defined as the dependent variables in the 
system differential equations, when the equations have been 
reduced, to first ordiir). 

d. Some outputs of a module may not be performance parameters. 

Outputs unrelated to the module's designated functions (e.g., 
power consumed and heat dissipated by an IMU) are "incidental 
outputs", not performance parameters. 

e. Some performance parameters of a module may not be outputs. 

Internal variables (either continuous or discrete) not normally 
output from a module will still be performance parameters, if 

they are real-world variables, and are essential to the. representation 
of the performance parameters which are outputs. 

f. Every variable available to a flight computer or telemetred for 
ground-controller use must be a performance parameter of some 
module. 

g. Inputs to a module are never performance parameters for that module. 
(This rule prevents double-counting; thus no variable will ever be 

a performance parameter for more than one module.) 

2. 1.1. 2 Critical Performance Parameters 

Guidelines for selection of a subset of critical performance from 
the set of performance parameters of a module appear somewhat less 
clear-cut than those for initial selection of performance parameters. 

A performance parameter may be denoted as a critical performance parameter 
for one or more of the following reasons: 

a. It is a particularly significant indicator of simulation validity 
for its associated module. 

b. Its accuracy has a long-term or cumulative impact upon the simu- 
lation validity; e.g., orbital drag forces, consumables expenditure 
rates . 

c. It is readily available to the crew (by permanent or callable 
display), and plays a key role in crew operational procedures. 

d. It is communicated to the flight computer(s) and plays a key 
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role in computer control of vehicle systems. 

2.1.2 Alternate Reference-Data Sources 

The Standards of Performance sought in WBS 2.2 are sources of 
reference data representing the real world, against which the 
simulation fidelity is to be evaluated. Four basic classes of 
reference- data source have been identified in this study: 

v o Closed-form solutions: exact or approximate formulas 
giving answers to be compared to the output of 
simulation routines. 

» 

1 o Independent math models: parallel software development for 

the explicit purpose of providing reference data for module 
validation. 

o Existing analysis/simulation programs: established, previously- 

validated programs which can be exercised with check-case data 
to provide outputs directly comparable to simulation module 
outputs. 

o Test data: vehicle and/or subsystem data from an actual 

laboratory or flight environment. 

Table 2-1 briefly lists advantages and disadvantages of each of the 
four basic classes of reference-data source. These considerations will 
be discussed in greater detail in a later report. 

2.1.3 Verification Techniques and Support Software 

Figure 2-1 depicts a support-software organization suitable for the 
generation, handling, comparison and display of simulation and reference 
data required to perform simulation software validation. A complete 
validation software system will consist of a basic "driver" or executive 
(denoted SOFCHK in the figure) and a set of service routines, briefly 
identified in Table 2-2. 

These routines will, of course, vary in degree of generality. 

Routines GENPT, SIMMOD, and CHKMOD must be completely "customized" for each 
simulator module being validated. Routine DREAD will be a data-driven 
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FIGURE 2-1. VALIDATION SOFTWARE OVERALL FLOW 
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TABLE 2-2. VALIDATION SUBROUTINES 9 


SUBROUTINE 

PURPOSE 

DREAD 

Reads records from a data tape or disc file 
generated during a simulator performance run; 
selects data for the appropriate module and 
places it into a data array. 

GENPT 

Generates a checkpoint which includes all data 
required for input into the module to be verified. 

SIMMOD 

Interfaces with the simulation software module 
and places the input and output data into a data 
array. 

CHKMQD 

Interfaces the "reference" software module and 
places the input and output data into a data array 
compatible with the simulation software data arr^y. 

DWRITE 

Writes the data from the simulator software module 
and the reference module onto a data file to be 
used for comparison processing. 

DSPLAY 

Processes the data file written by DWRITE. 

Performs automated comparisons of simulation and 
reference data, and/or generates listings and plots 
for manual comparison of data. Incorporates a 
variety of differencing techniques and comparison 
criteria. 


a Math flows and comprehensive discussions of these routines 
will be provided in a later report. 
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Input routine, designed to be compatible with the basic data-output 
structure of the simulator being validated. Finally, routines DWRITE 
and DSPLAY should be highly independent of the characteristics of the 
module being validated. The greater the degree of generality designed 
Into the support software, of course, the less specialized coding and 
setup required to validate each individual module. 

Subsequent sections of this report describe some of the customized 
modules required to support validation of individual simulation modules. 
Designs for the validation executive and the generalized support routines 
will be presented in later reports. 
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.2.2 ENVIRONMENT MODULES 

Environmental conditions external to the Orbiter vehicle interface with 
and influence the performance of the Shuttle systems and/or vehicle. These 
environments can be divided into two basic divisions, natural and artificial. 

The natural environment includes those conditions which occur in nature. The 
artificial environment includes the man-made or artificially created conditions. 
These two groups are discussed in this section. 

2.2.1 Natural Environment 

Several natural factors Influence the Orbiter vehicle performance, dynamics, 
and navigation. This section identifies these natural factors, section module 
functions, and parameters related to the module, and suggests a technique for 
verification of the module. 

2. 2. 1.1 System Description 

The natural factors influencing vehicle performance are atmosphere, wind, 
gravitation potential, sun/moon/star ephemeris, and terrain elevation. The 
atmosphere and wind impact the Orbiter aerodynamically, producing forces and 
moments. The trajectory of the vehicle is influenced by the gravitational 
potential. The locations of the sun, moon, and stars provide guidance and 
navigation inputs. The terrain near the landing site reflects the radar altimeter 
signals for altitude measurement during the final approach and landing maneuvers. 

2. 2. 1.2 Module Functions and Parameters 

The Natural Environment Module provides the inputs required to simulate 
their influences. Figure 2-2 provides a possible module configuration and 
Interfaces with the other modules. Table 2-3 gives the list of parameters 
associated with the module. The functional elements within the module are described 
below. 

Atmosphere and Hind 

The atmosphere and wind element provides the following functions: 

- Dynamic pressure - a function of density and relative velocity- 
of the Orbiter and air stream. 

- Mach number - a function of air temperature, air velocity, and 
vehicle velocity. 
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FIGURE 2-2 . NATURAL ENVIRONMENT MODULE, FUNCTIONAL ELEMENTS AND INTERFACES 
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TABLE 2-3 . NATURAL ENVIRONMENT MODULE PARAMETERS 


SYMBOL 

PARAMETER 

TYPE a 

T 

Universal Time 

I 

fi 

Vehicle Position vector magnitude 

I 

0 

Vehicle Position Latitude 

I 

O' 

Vehicle Position Longitude 

I 

R 

Inertial Position Vector 

I 

Ee 

Earth fixed position vector 

I 

- 

vehicle attitude, rates 

I 

h 

Vehicle geometric altitude 

I 

a 

Vehicle geopotential altitude 

I 

- 

Locations (sun, moon, stars) 

CP 

6 

Earth gravitational acceleration 

CP 


vector 


S 

Sun line-of-sight vector 

CP 

M 

Moon vector 

CP 

q 

Dynamic Pressure 

CP 

M 

Mach number 

CP 


Angle of attack 

CP 


Side slip angle 

CP 

e 

Atmospheric density 

p 

■ p 

Atmospheric pressure 

p 

- 

Atmospheric Temperature 

p 

v s 

Speed of sound 

CP 


Wind Velocity 

p 

e T 

Terrain elevation 

CP 


a Legend = I = Input 

P = Performance Parameters 

CP= Critical Performance Parameters 
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- Angle of attack/side slip angle - functions of air velocit.es, 

Orbiter velocity, and Orbiter attitude. 

Gravitational Potential 

This element provides the force, due to the earth mass, acting on the 
vehicle. This force is a function of the mass, distance, location of the 
vehicle, and includes the zonals, sectorals, and tesserals harmonic terms. 

Sun/Moon/Star Ephemeris 

The ephemeris provides the position of the sun, moon, and stars as a 
function of time. 

Terrain 

The elevation of the local landing terrain as a function of vehicle 
position is provided by this element. 

2. 2. 1.3 Module Verification 

The comparison method described in Sect. 2.1.3 is particularly applicable 
for verification of the simulator environment model because most of the software 
models required to verify the environment are available for the reference module. 
Verified software representing the potential and atmosphere models is available 
from the digital programs described in References 1, 2, and 3. Reference 1 also 
documents an ephemeris routine which can be used to verify computation of the Sun 
and Moon vectors. In applying the method to the environment the functions 
performed by GE‘JPT and CHKMOD (Figure 2-1) must be defined. 

To verify the environment model, position vectors and time points must be 
generated to sequence all logic paths of the potential model, atmosphere model, 
terrain model, ephemeris model, and wind model. Assume GENPT calls a routine 
GENRT (Figure 2-3) to provide these check points. By making the altitude and time 
increments small enough all loops will be sequenced. 

ENVIOR (Figure 2-4) represents a typical environment model to be called by the 
routine CHKMOD. The input to ENVIOR is a position vector, R, and a Universal 
Time, T, which are generated in GENRT or read from a performance run. The 
parameters which are to be verified are presented in Table 2-3. These parameters 
are placed in the data array for comparison pfqcessing. 
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Relative to Figure 2-4, the transformation from an inertial frame to an earth 
fixed frame is discussed in Reference 4 and the atmosphere, potential, and Ephemeris 
models necessary to compute density, pressure, speed of sound, gravitati 1 accel- 
eration, and the sun and moon vectors are discussed in Reference 5 . 

The software required to verify these models is available in a variety 
of analysis programs. However, the terrain and wind models are dependent 
on the type of mission being simulated and the accuracy required. For example, 
the wind model could represent a nominal wind with random turbulence added 
using a filter for nominal runs, or the wind model could represent extremes 
and be used for engineering test runs. Models for the wind and terrain have 
been Implemented on the MDAC Shuttle Mission Engineering Simulator in St. Louis 
and software for these models is available. The models and typical results are 
documented in Reference 6. However, detailed, user-oriented documentation is 
not presently available. In any case, care should be taken to assure that the 
reference software for the winds and terrain represent the same model as the 
simulator model . 

2 . 2.2 Artificial Environment 

Several artificial environments exist which interface with the Orbiter 
vehicle . These environments include: 

- Ground Navigation/Communications 

- Payloads and Rendezvous Targets 

- Prelaunch/Launch Interface 

These three modules are discussed in this section. 
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2.2.2. 1 Ground Navigation/Communications 

Various radio frequency interfaces between the Orblter and the 
ground provide Navigation and Conmuni cations capabilities. This 
section provides a description of a representative Space Shuttle 
Ground Navigation/Communications subsystem, Identifies the Ground 
Navigation/Communications module interfaces with other modules, 

Identifies the parameters and functions associated with the module, 
and provides a flowchart technique for performing th'e verification 
of the module. The detail is general, but is appropriate for the 
pu>po$e of the techniques study. 

System Description 

The ground navigation/communications network provides the radio 
frequency conmuni cat ion interface to the Shuttle Orbiter navigation/ 
communications subsystem. Review of the Orbiter Nav/Comm subsystem 
Indicates the following ground system capabilities are required. 

Dual antenna S-band telemetry reception. 

UHF "voice" reception and uplink. 

STDN/TDRS transponder reception and uplink. 

SGLS transponder reception and uplink. 

Radio Frequency Navigation Aids uplink. 

These interfaces are provided by various combinations of ground 
based and satellite equipment, primarily antennas receivers, and 
transmitters. The one exception to this is the radar altimeter which 
depends on the ground reflection of the Shuttle transmitted signal 
for proper operation. The performance characteristics of the primary 
equipment and the site (and satellite) location determine the proper 
operation of the navi gation/communi cation system. 

The equipment characteristics of major concern are those of the 

receivers, transmitters, and antennas. The receivers have two 

primary characteristics of interest, tuned frequency and output power. 

The ar.tenna characteristics are frequency band, gain and gain pattern. 

Secondary antenna pattern affects are caused by antenna gimbal drive 

limits and local terrain interference, causing the site coverage 
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capability to vary with azimuth and elevation angle of line-of-sight 
to the shuttle. 

Module Functions and Parameters 

Figure 2-5 provides an overview of the Navigation/Communications 
Ground Station Module functional elements and interfaces with other 
modules. There are basically five functions performed within the 
module. These functions are to determine proper conditions, signal 
strengths received, and signal strengths radiated, locations, etc. 
for each of the following communication or navigation subsystems. 

. Dual S-band telemetry reception. 

. UHF voice communications. 

. STDN/TDRS transponder communications. 

. SGLS transponder communications. 

. Navigation Aids uplinks. 

Table 2-4 provides a listing of the parameters associated with the 
Module and the designation of parameter type. Section 2.1.1 provides the 
criteria used in determining the parameter type. The functions performed 
by each element and the factors involved in calculations are as follows. 

Dual S-Band Telemetry Reception Element - The Dual S-Band element performs 
the following functions for the reception of Shuttle FM transmitter, 

TLM transmitter, and DF1 transmitter data. 

- Make proper station (Ground) selection-function of station 
location, capabilities, and vehicle location, transmission 
frequency, etc. 

- Determine adequate received signal strength-function of 
vehicle attitude, range, cntciir.a gain pattern, radiated 
signal level; ground station location, tracking antenna 
gain pattern (azimuth, elevation angle), receiver 
sensitivity, vehicle transmitted signal. 

- Enable/disable reception of proper telemetry downlink with 
appropriate noise level, etc. 
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Table 2-4 . CROWD NAV/COMM SUBSYSTEM PAfAMETERS . 


Parameter Type a 


Shuttle vehicle position, attitude, velocity I 

anutue antenna selection taqs (Qua 1 and Quad S-Uand) I 

Shuttle transmitter active flags 

(FM, TLM, DFI,’ UHF, STDM , SGIS) I 

Shuttle selected channel (frequency) taqs 

(MSbLS , TACAN, UiiF) I 

Shuttle selected STDK/TDRS transmission mode tag I 

Shuttle Receiver active flags (TACAN, MSLLS) I 

Shuttle Radar Altimeter flag I 

Ground station inhibit flags I 

Shuttle/station line-of-sight contact flaos 

(UliF, STDN/TDRS, SGLS, TACAf; , MSBLS) CP 

Ground station selection tags 

(FM, TLM, IT I, liHF, ST DM, SGLS, TACAN , MSBLS) 

Ground station reception enabled flags 

(FM, TLM, DFI, STDti/TDPS, SGLS, UHF) C 


Ground Station antenna tracking angles 
Ground Station position coordinate 

(FIT, TLM, DFI, STDN/TDRS, SGLS, UliF, TACAii, MSBLS) 

Shuttle/Ground station Range 
Ground station received sianal strengths 

(FM, TLM, DFI , STDN/TDRS , SGLS, UHF,) | C 

Code identification and tone enable (TACAII,HSbLS) 

Ground selected station frequency (TACAN, MSbLS, UiiF) 

Local Terrain Altitude 


’Legend: P = Performance Parameter 

CP = Critical Performance Parameter 
I * Input Parameter 


; ;UiY OF THE 
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UHF Voice Communications Element - The UHF voice communications 
element functions are the same as the Dual S-Band Telemetry Reception 
Element except that the data enabled is downlink voice, and the 
following addition: 

- Calculate and output the ground transmitted signal strength- a 
function of transmitter power, antenna gain patterns, range, 
elevation angle, azimuth, atmospheric attenuation, etc. 

STDN/TDRS Element - The STDN/TDRS Element performs the following functions: 

- Make proper ground station selection-function of station 
location capabilities; vehicle location, satellite position, 
etc. 

- Determine adequate received signal strengths-function of 
vehicle transmitted signal strength, antenna selected, 
antenna gain pattern (azimuth and elevation angle), receiver 
sensitivities, mode selected, satellite position, etc. 
Enable/disable data reception. 

- Determine and output transmitted signal strength-function of 
transmitters power, antenna gain patterns, range, elevation 
angles, azimuth, etc. 

- Determine Doppler- function of ranges, range rate etc. 

SGLS Elemen t - The SGLS functions are the same as the STDN/TDRS element 
except for the SGLS frequency, no TORS, and different ground station 
locations, etc. 

Navigation Aids Element - This element provides for TACAN and MSBLS 
transmissions and local terrain altitude. 

- TACAN functions: 

Make proper ground stations selection-function of 
selected frequency, vehicle location, etc. 

Determine ground transmitted signal strength-function 
of transmitter power, antenna gain pattern, vehicle 
elevation angle, azimuth, etc. 
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Output station identification tone enable, station 
frequency, station location, and transmitted signal 
strength. 

* MSBIS functions: 

Make proper stations selections-function of vehicle 
location, selected frequency, etc. 

Determine ground transmitted signal strength-function 
of transmitter power, antenna gain pattern, vehicle 
location, etc. 

Output station identification code enable, station 
location, run way heading, transmitted signal strength, 
frequency, etc. 

- Local Terrain functions: 

Determine local terrain altitude-function of vehicle 
location, azimuth, radar altimeter on/off, etc. 

Output altitude of terrain. 

Module Verification 

The verification technique presented in section 2.1.3 can be used 
for verification of the Ground Navigation/Communications module. Figure 2-1 
provides the basic flow chart for the technique. The subroutine "CHKMOD" 
in Figure 2-1 is provided by the validator and represents a software model, 
test results, analysis results, etc. selected by the parameter values 
determined by the subroutine "GENPT". Figures 2-7 thru 2-12 provide the 
drivers necessary to complete "GENPT". Figure 2-6 provides the determin- 
ation of completion of all desired checkpoints. The proper use of this 
or a similiar technique and proper selection of various driver conditions 
will provide a thorough verification of the simulation module and related 
data files for station locations, equipment, etc. Each "check point", 
accuracy, and reference data are under the control and selection of the 
validator. 
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FIGURE 2-10. STD?.' /TORS TRANSPONDER DRIVER (STDH DRVR) 
FLOW CHART. 
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FIGURE 2-12. RADIO FREQUENCY NAVIGATION AIDS DRIVER (NAV AID DRVR) 
FLOW CHART 


2-30 

MCOONNCLL DOUGLAS ASTRONAUTICS COMPANY - HAST 









MDC Ell 27 
1 August 1974 


Provisions - This technique provides the following capabilities. 

- Initialization of Parameters. 

- Interfacing module drivers. 

- Multiple evaluations during a single run. 

At the start of each run, with the exception of the Equations of 
motion drivers, the Interfacing module parameters are initialized to 
the "off" conditions. The parameters remain In "off" conditions until 
that portion of the module is selected for verification. When the 
portion has completed verification the parameters are again returned 
to the "off" condition. 

Those input parameters normally provided by interfacing modules 
are provided by the module drivers. The values of the parameters are 
determined by the validator. Ground station locations, etc, data files 
will be accessed as required by the simulation module and therefore 
should not require a driver or any special verification. The following 
drivers were identified: 

- Equations of Motion-provides shuttle vehicle location, 
attitude and velocity, etc. 

► Dual S-Band Telemetry-provides antenna selection, and 
transmitter signal strengths. 

- UHF -provides UHF frequency selected and transmitted UHF 
signal strength. 

- STDN-provides mode selection (STDN or TORS), antenna 
selection, and transmitted signal strength. 

- SGLS-provides antenna selection and transmitted signal 
strength. 

- NAV. AID-provide selected TACAN and/or MSBLS frequency, 
and TACAN, MSBLS, and Radar altimeter on/off selections. 
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The Equation of Motion driver is active for each check 
case with a complete cycling of its conditions for exercise of 
each of the other driver (s) conditions, Each of the remaining 
drivers is cycled only once during each run with all other 
driver's conditions remaining constant. This allows the 
verification of any one or all portions of the module for a 
particular set of vehicle positions, altitudes, etc. This 
verification should thoroughly exercise the Ground station data • 
files, locations, etc, in order to provide the correct answers. 

2.2. 2.2 Payloads and Rendezvous Targets 

A variety of payloads and rendezvous targets will exist for possible 
use with the Shuttle Orbiter. Tnis section provides a description of the 
Payload/Rendezvous Target Module. The description defines the Module 
functions, interfaces with other modules, associated parameters, and briefly 
discusses techniques for verification of the module performance. 
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System Description 

A wide variety of possible rendezvous targets and payloads exist for the 
Shuttle missions. The variety of satellites, modules, upper stages, 
experiments, etc. Include the following: 

Cryo tug 

Agena high energy payload 

Interim tug 

Large Space Telescope 

ESRO Space lab 

Earth observation satellite 

Shuttle Orbiters 

A portion of the Orbiter payload may consist of Mission Extension Kits. 

These kits provide addition consumables such cs fuel, oxygen, nitrogen, hydrogen, 
crew equipment, etc. necessary to allow additional stay in space. The functions 
provided by these kits are included in their support module and are not included 
in this section. 

There are basically three modes of Payload Operation. These modes are stowed 
(retained), on-manipulator arms, and released modes. The released mode and 
Rendezvous Target operation are very similiar and will be combined for this 
discussion. The interfaces between the payload vehicle and the Orbiter for each 
of these modes are defined next. 

Payload Stowed/Target Docked - The stowed/docked phase has the following interfaces 
with the Shuttle Orbiter systems. 

(a) Dynamics: The payload/Target Mass is integral with the urbiler mass 

properties. There is a constant relationship between payload and orbiter 
attitudes, state vector, body rates, etc. 

(b) Electrical Power: The payload may receive electrical power from the 

Orbiter during this phase. 


iUOIBiLIi'x c)K Ulls 
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(c) Environmental Control: The ECS may have several interfaces: A 
thermal heat load from the payload is supplied to the Orbiter Active 
Thermal control system via the Payload heat exchanger. Gaseous 0g/N 2 
may be provided to the ARPCS . The Payload/Target volume may require 
pressurization and pressure control by the Orbiter ARPCS . 

(d) Communications/Instrumentation: The communication between the Orbiter 
and Payload is via the umbilical. Interfaces include hardline audio 
(voice), video (TV) from payload camera, commands to payload from the 
Orbiter Payload signal processor, and instrumentation data from the 
payload to the Orbiter FM transmitter. 

Payload/Target On - Manipulator Arms - During this phase of operation umbilicals 
are disconnected and all communications must be via Radio Frequency link. 

(a) Dynamics: The payload mass properties are coupled to the Orbiter mass 

properties via the manipulator arms. The payload attitudes, rates, state 
vector, etc. are related to the Orbiter parameters. The relative range and 
attitudes affect communication and visual views. 

(b) Communications & Instrumentation: The voice communications and commands 
from the Orbiter are transmitted via the Payload Interrogator RF link. There 
are two interrogators with 40 channels each. Twenty of these channels 
provide Air Force payload telemetry and command transfer capability. The 
Interrogator (Orbiter) transmitts two watts via a S-Band antenna with a 
limited antenna gain pattern. Minimum range and maximum range modes of 
operation are available. 

(c) Visual: Out-the-window views and TV cameras provide optical 
information, concerning the payload configuration, relative range, 
and relative attitudes. 
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Payload Detached/Rendezvous Target - All communications are via the RF links. 

(a) Dynamics: The Payload/Target mass properties, attitude, state 

vector, etc. are independent of the Orbiter. The relative attitude and 
range influence the communications and visual views. 

(b) Communications/Instrumentation: Communication is via the Payload 

Interrogator, or S-Band transponders. Payload Interrogator functions are 
the same as in the on - manipulator arms mode. The S-Band transponders 
provide communication between two Shuttle vehicles. Communication includes 
voice, commands, or telemetry data transmitted via SGLS transponder 

(Air Force) or STDN/'TDRS transponder (NASA). 

(c) Rendezvous Radar: The radar provides range, range rate, angle, and 
angle rate information during rendezvous. The radar operates in two modes: 
passive target (include passive enhanced) and active enhanced cooperative 
targets. The passive mode receives a reflected signal from the target for 
operation. The active mode is dependent on the target receiving, shaping, 
and returning the radar signal. 

(d) Visual: Similar to the on-manipulator-arms mode, with less detail 

apparent at increasing distances. 

Payload/Tarqet On-Board Systems - Shuttle payloads may include a wide variety 
of onboard systems - electrical, hydraulic, avionic, etc. Some of these systems 
will affect the visual configuration, attitude, or range. 

For example the attitude control system would null rates, maintain attitudes, 
etc. which would stabilize the Target during rendezvous or docking. These 
on-board systems would be similiar to shuttle systems, to be described in 
later reports. The parameters, techniques, etc., covered in the context of 
Shuttle onboard systems should be adequate for use for the Payload/Target on- 
board systems. Therefore no further effort will be expended on those systems. 
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Module Functions and Parameters 

The Payload/Target Module provides the following functions: 

- Umbilical interface logic 

- Payload Interrogator interface 

- Rendezvous radar interface 

- S-Band transponder interface 

- Payload/Target on-board Systems 

Figure 2-13 identifies the module functional elements and their interfaces 
with other modules. The visual display model inputs are shown for completeness. 
The parameters associated with the module are presented in table 2-5. It should 
be remembered that the "on-board systems" element parameters are not included 
in the table. The functions of each of the functional elements are discussed 
bel ow. 

Umbilical Interface Logic - This module provides the enabling logic for payload 
video, hardline payload commands, audio communication, and payload instrumentation 
via the Orbiter FM transmitter. The logic is a function of umbilical connection, 
payload logic (electrical power, switch positions, etc.) 

Payload Interrogator Interface - This module provides suitable response for 
communications via the Orbiter payload interrogator: 

- Determines adequate signal strength from Orbiter - A 
function of transmitted power, transmitted antenna 
gain pattern, receiving antenna gain pattern, range 
vehicle attitudes, receiver sensitivity, 1 ine-of-sight, 
enabling logic, etc: 

- Transmit/Signal Strength Flag - Function of enabling 
logic for payload transmitter. 

- Enables Interrogator Commands - Function of receiver 
sensitivity and received signal strength. 

- Enables Audio reception (via interrogator) - Function of 
received signal strength and receiver sensitivity. 
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FIGURE 2-13. PAYLOAD/RENDEZVOUS TARGET MODULE, FUNCTIONAL ELEMENTS AND INTERFACES 
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TABLE 2-5.PAYL0AD/TARGET MODULE PARAMETERS 


PARAMETER 

a 

TYPE ! 

Shuttle/Payload Umbilical connected/disconnected flag 

I 

Shuttle selected control logic Inputs 

I 

Vehicle positions, attitudes, velocities, rates 

T 

(Shuttle, Payload/Target) 

A 

Shuttle Quad Antenna selection tags (S-Band) 

I 

Shuttle transmitter active flags 


(S-Band transponders. Radars, interrogators) 

I 

Shuttle selected STDN/TDRS transmission mode 


Shuttle selected interrogator channel tag 

I 

Shuttle selected interrogator range max/min tag 

I 

Shuttle Radar antenna gimbal angles 

I 

Payload/target on-board systems input parameters 

I 

Shuttle Radar mode (transponder/reflection) tag 

I 

Payload/Target Received signal Strength 


(S-Band transponders. Radar, Interrogator) 

CP 

Payload/Target Reception enabled flags (S-Band Transponders, 


Interrogator, Umbilical) 

CP 

Target Radar signal reflection factor 

p 

Payload/Target S-Band transponders Doppler 

CP 

Payload/Target transmitter active flags 

p 

(S-Band Transponders, Radar, interrogator) 

r 

Payload/Target On-Board Systems parameters 


(Instrumentation, Thrusters, Self- test, etc) 

p 

Payload/Target Mass properties parameters 

p 


2 Legend: I = Input 


P = Performance Parameter 

CP= Critical Performance Parameter 
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Rendezvous Radar Interface - The Rendezvous radar interface provides the 
following functions: 

- Determines Radar signal Reflection factor - A 
function of vehicle attitude, incident angle. 

- Determine adequate Received Signal Strength - A 
function of transmitted powers, vehicle attitudes, 
antenna gain patterns, range, 1 ine-of-sight, receiver 
sensitivity. 

- Determine transmitted signal flag - A function of 
received signal strength, control logic. 

S-Band Transponders Interface - There are two transponders: STDN/TDRS 
(NASA) and SGLS (Air Force) which provide the following functions. 

- Determine adequate received Signal Strength - A 
function of transmitted signal strength, antennas 
selected, gain patterns of antennas, range, 
line-of-sight angles, receiver sensitivity. 

- Enable/Disable command, voice, or instrumentation 
'reception. 

- Determine and output transmitted signal Strength flag - 
Function of on-board control logic. 

- Determine Doppler - Function of received signal 
strength, ranges, range rate. 
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Module Verification 

The verification of the Payload/Rendezvous Module can be accomplished 
using the basic technique developed for other systems module. Figure 2-1 
provides a flowchart for this basic technique. The technique involves 
the generation of module input and initialization data via drivers 
(program GENPT) for each checkcase or condition for which a reference exists. 
The reference (program CHKMOD) may be specific test results, analysis results t 
independent simulation results, etc. The reference data and the simulation 
results for each checkcase are compared (program DSPLAY), and output for 
evaluations of accuracy and future reference. By proper design of the input 
drivers and checkcase conditions a thorough evaluation can be made. 

From Figure 2-13 drivers for the following functions (interfaces) will be 
required: 

- Equations of Motion 

- Payload/Target mass properties 

- Payload/Target on-board systems conditions 

- Command Generator 

- Payload interrogator 

- Rendezvous Radar 

- S-Band transponders (SGLS and STDN/TDRS) 

- Umbilical Control logic 

The fallowing types of data will be required to develop reference 
checkcases or direct use as a reference. 

- Antenna gain and patterns - This data should be 
available from analysis and scale model tests, 
and should eventually appear in reference 8. The 
other results would be included in the specific 
test report or analysis report. 

- Transmitter output power - The actual output radio 
frequency power would be available from design 
anaylsis and acceptance testing of the transmitters, 
and should eventually appear in reference 8. The 
test reports and analysis results would normally 

be available from equipment or vehicle contractor. 
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Receiver sensitivity - This data should be available from 
design analysis, and acceptance testing of units, and should 
eventually appear in Reference 8. The equipment manufacture 
or vehicle contract should supply the test reports etc. 

Control logic - Would normally be available from system 
schematics, wiring diagrams, analysis, and systems check-out 
or integrated testing. 

Radar signal reflections factors (coefficients) - data for 
various incident angles, directions for the various rendezvous 
targets. This data could be available from analysis or possibly 
model testing or other simulations. 

Radio frequency cabling and switch losses - The power loss within 
the vehicles due to the cable lengths, etc. This type data should 
be available from analysis of cable types, lengths, or fr~m systems 
tests. This data would normally be available from vehicle contractor 
system designers and manufacturing personnel. 
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^laiineh/Launch Interface 

,-jl Interfaces exist between the ground (launchpad) and the 
' tcr» External Task, and Solid Rocket boosters during 
s ac . •. i*-,e of the launch countdown. This section provides a 


final P h 


s ,.f;tio n a lso defines the module functions, associated 


the ,,f the functions for possible simulation 

descript' 01 

This 

■rs* interfaces W1 ’th other modules, and discusses briefly 

paramo ■ verification of the module performance, 
a tech ni‘l 111 

„ , . rip tion _ 

Systent P--’ '• * 

o^rladnch/Launch Interface provides the ground controls interface 

yjlfj I * 

lie v i •’ ^ wo ^ aunc ^ unibi 1 i cal s (see reference lo), radio frequency 
aVa11a > . ( , .m<l the mechanical "inhibits" (such as vehicle strap downs) to 
interfa j. crna i Tank/Solid Rockets configuration. These interfaces 

i,L « i-* 1 ' 

r . ,,v..ii ablG t0 the configuration during the period T-2 hours to 
are tho ^ Q f the countdown. The system interfaces are as follows: 


launch P* 1, 


The* 0 


interfa c ° 


- Communication and Instrumentation 

- Electrical Power 

- Environmental Control 

- Hydraulics 

- Propulsion 

- Mechanical 

functions are considered for simulation in the Prelaunch/Launch 
tule. 


IIX" 


Commit n 
hardl i»‘ 
frequency 


and Instrumentation - Those interfaces available are the 

tea' 


. en" 1111 


adds , hardline telemetry, radio frequency commands, radio 


L)! |(*mutry, and radio frequency voice. 
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Electrical Power - Electrical DC bus power to the Orbiter's three buses is 
available via the launch umbilical. Ground support equipment also provides 
GH 2 and GOgto the Power Reactants distribution system to supply fuel cell 
and environmental gas during the prelaunch phase (Reference 7). 

Environmental Control - Purge lines (see Reference 9) are provided for GN 2 
structural and bay area purges. External Tank cryogenic disconnects GH 2 

purge, and entry GHe purge (windshield, front wheel well.) The umbilical 
also provides lines for circulation of coolant fluid to the GSE heat exchanges 
(see Reference 11) interfacing with the Active Thermal Control Freon subsystem 
(Primary and Secondary) . 

Hydraulics - The launch umbilical provides lines for auxiliary power unit 
helium fill. It also provides hydraulic fluid lines for the circulation of 
hydraulic fluid by a GSE pump, (See References 12 and 13) . 

Propulsion-Lines are available to provide External Tank LH 2 and L0 2 

fill/drain/dump, and prepressurization functions; GN 2 MPS purge; and MPS 
helium supply. 

Mechanical - The mechanical release of the launch umbilicals, launch 
umbilical doors, and vehicle strapdowns occur at approximately T=0. 

Prelaunch/Launch Interface Module Functions and Parameters 

Figure 2-14 provides an overview of the Prelaunch/Launch module functional 
elements and interfaces with other modules. The module performs functions 
associated with the following activities: 

(a) Communications and Instrumentation 

(b) GSE Electrical Power 

(c) Environmental Control 

(d) Hydraulics 

(e) Propulsion 

(f) Control logic 
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FIGURE 2-14. PRELAUNCH/LAUNCH INTERFACE -MODULE, FUNCTIONAL ELEMENTS AND INTERFACES. 
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Table 2-6 provides a listing of the parameters associated with 
the module and a designation of parameter type. The functions 
performed by each element and the factors Involved in calculations 
are as follows: 

Communications and Instrumentation - This element provides the logic 
for launch/prelaunch enabling of Launch Umbilical Commands, Instrumentation 
and ground functions Involved in the radio frequency communications 
(voice, telemetry, commands). These functions are dependent on the ground 
facilities configuration, switch selections, etc. 

GSE Electrical Power - This element defines the value of the GSE-supplied 
bus voltages and Power Reactants Storage and Distribution GSE supplied 
pressure for G0 2 and GH,,. These outputs are functions of the ground 
equipment control logic, countdown timeline, etc. 

Environmental Control Support - The ECS support outputs the GSE supplied 
pressures and temperatures are functions jf the ground control logic, 
etc. In addition it also provides the GSE heat exchange fluid outlet 
temperatures to the Active Thermal Control Subsystem (Primary and 
Secondary loops). The temperature is dependent on the Orbiter loops 
fluid flow rate and GSE heat exchanger inlet temperature, GSE control 
logic, and heat exchanger heat transfer properties. 

GSE Hydraulic Support - This element provides the GSE fill pressure 
and temperature for the Auxiliary Power Unit He fill. This pressure 
and temperature are determined from the GSE control logic. The element 
also provides the GSE hydraulic pump pressure rise for Jriving the 
Orbiter hydraulic systems during prelaunch. This pump pressure is 
related to the GSE control logic. 

GSE Propulsion Support - The element determines the GSE supplied pressures 
and temperature for the following activities: 

- MPS GN 2 Purge 

- MPS He supply 

• a 

- He prepressurization 

2-45 

MCDONNELL DOUGLAS ASTfTOMAUTICS COMPANY « EAST 


MDC El 1 27 
1 August 1974 


TABLE 2*6, P RE LAUNCH/ LAUNCH INTERFACE MODULE PARAMETERS. 

PARAMETER 1 TYPE a 


Ground launch control input logic (countdown, GSE 
Switches, etc.) 

I 

Active Thermal Control loops inlet temperatures and 
flow rates to GSE heat exchangers (Pri and Sec) 

I 

Active Thermal Control loops outlet temperatures from 
GSE heat exchanger (Pri and Sec.) 

CP 

GSE Supplied bus voltages (to Orbiter buses 1,2,3) 

P 

GSE Hydraulics pump(s) pressure rise 

P 

GSE Supply Pressures/Temperatures to PRS&C (G0 2 and GH 2 ) 

P 

GSE fill pressures/temperatures (LH 2 , L0 2 APU GHe) 

P 

GSE MPS He supply pressure/temperature 

P 

GSE MPS Prepressurization pressure/temperature 

P 

GSE Purge Pressures/temperatures (GN?, GHe 

MPS*GN 2 , Reentry GHe) 

P 

Vehicle strapdowns released 

CP 

Launch Umbilical Doors released 

CP 

Launch Umbilical s Instrumentation Reception enabled 

p 

Launch Umbilicals Commands enabled 

p 

Ground RF Communications enabled 

p 


a Legend: 

I = Input 

P = Parameter 

CP = Critical parameter 
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-G0 2 fill 
-GH 2 fill 

These pressures and temperatures are functions of the ground 
equipment capabilities and the GSE control logic. 

GSE Prelaunch Control Logic - This element performs the logic 
functions required to control the various prelaunch activities. 

It generates the logic for enabling prclaunch communications, 
instrumentation, command transfers for strapdown releases, 
lift-off indication, engine start, etc. per the countdown sequence. 

Prelaunch/Launch Interface Module Verification 

The drivers required to provide the necessary inputs for verification are: 

- GSE Control logic Inputs 

- Active Thermal Control - GSE Heat exchanger 
inlet fluid temperature and flowrate. 

These drivers are used to provide the inputs. The module outputs are ' -■> compared 
to the expected prelaunch ground interface values. 

The electrical power voltages and the purge, supply, and fill pressures and 
temperatures can be determined from the ground support equipment capabilities, and 
planned inputs. These can be determined from the checkout procedures, countdown 
procedures, and GSE equipment specifications (not identified at this time). 

The prelaunch sequences, and countdown procedures, time-line, etc. should 
provide the necessary information to verify the Prelaunch Control logic. These 
documents are not curv«.ntl,y available and have not been identified. The values of 
the gas pressures, temperatures, will most likely be static during the time frame 
for the simulation and approximating the systems maximum operating pressures. 


' '"UTILITY OF THU) 
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2.3 CREW STATION MODULES 

irt the crew's 

Visual and motion simulation are of crucial Importance 

r u ' reel ^^(1. 

subjective perception of the fidelity of representation ot ^ 

However, objective validation of visual/motion driver modules i 

difficult by the highly hardware-peculiar nature o r these modu 

section briefly describes the subject modules and .heir interfaces w 
. , _ . . , _ f j nr is for validation 

simulation hardware and software, and makes some suggestions 

at the module level. Techniques for integrated validation of 

motion systems will be discussed in a later report. 

2.3.1 Visual Drives 

2. 3. 1.1 Module functions and parameters 

« ,r , . hotween the various 

Figure 2-15 provides an overview of the interfaces bee 

, election logic 

visual-drive submodules and the rest of the simulation. l 

* xl , fl --th globe, terrain 

for the various sources of visual -scene information -- earu ’ y 

model, CIG, etc. -- is based upon mission-phase and operaTi 

4. „ v , crpne source has its 

discretes, as well as the current state. Each visual -scene ^ 

own driver module, which may include coordinate transit ('.nation, sea ing, 

compensation, and mechanical limit checks. The driver for 1 ^ 

image generation (CIG) module, used for manipulator-arm visuals* wi e 
. ^ p „ transformation and 

somewhat simpler, since the CIG will do much of its own tran» 

. , , , , limit checks* 

scaling, and does not require mechanical compensation or n»‘ 

T * . n « , . . i Hri ve modules. 

Table 2-7 provides a parameter nst for the visuai-o' 


2. 3. 1,2 Module Validation Exercises 

, , , , types of validation 

In the absence of vi sual -system hardware, the foil own j 

exercise can be performed on visual -drive modules: ro ^ 

(a) Verify that the visual -system control module outputs P P 

J v. J-U.itru , , for various 

subsystem-level commands to the various submoaui 

§ and 

combinations of state variables, mission-phase 


(b) 


operational -mode discretes. 


„r„rtness of transform- 

For each submodule, graphical!* verify the <*** of parameters 
atnon. scaling and travel limit checks over th mensjona , 

for which that submodule is to be employed. A t way t0 handlc 

plotting capability will probably* be the most cut 

j an GXlST/incj ujU 

these submodule outputs. Reference 31 descri 
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TABLE 2-7. VISUAL -DRIVE MODULE PARAMETERS 


SYMBOL 

DESCRIPTION 

TYPE 3 

r» y 

Vehicle position & velocity vectors 

I 

f, °,f 

Vehicle Euler angles 

I 

6r» 5v 

Multiple-body relative position & velocity vectors 

I 

6f, ^ 

Multiple-body relative Euler angles 

• I 

— 

Vehicle latitude, longitude, altitude 

I 

- 

sun/moon/star ephemerides 

I 

- 

Mission-phase and operational -mode discretes 

I 

- 

Submodule activation commands 

P 

- 

Visual hardware scaling, lags, limits, etc. 

I 

- 

CI6 imagery data base 

B 

- 

earth globe position commands 


— 

terrain model carriage & optical probe commands 


- 

target model & camera track and gimbal commands 

CP 

_ 

CIG driver conmands 

CP 


a Legend: I s input 

P - performance parameter 

CP= critical performance parameter 
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software package which should provide adequate capability for this exercise. 
2,3,2 Motion-Base Drives 

2. 3. 2.1 Module functions and parameters 

Motion-base drive software is even mote hardware-dependent than visual 
drive software, for two basic reasons: First, the "synergistic" motion-base 

design recommended for Shuttle simulators (Fig. 2-16, from Ref. 24 ) does 

not allow any simple correspondence between vehicle degrees of freedom 
and actuator degrees of freedom. Motion in any individual vehicle degree 
of freedom -- roll, pitch, yaw, plunge, heave, or sway -- will require . 
displacements of all actuators. Second, the limited actuator travel 
available prevents simulation of sustained accelerations. As shown in 
Fig. 2-17, the software must provide a look-ahead capability to gently 
"wash out" actuator commands without hitting displacement stops and 
causing an abrupt deceleration. Additional small -magnitude commands are 
used to "bleed back" the actuators to their null position, to provide 
travel freedom for the next large motion which may be required. 

Table 2-8 provides a parameter list for the motion-base drive module. 

2. 3. 2. 2 Module Validation Exercises 

It should be clear from the above description that objective validation 
of motion-base drive software is difficult or impossible, largely because 
the motion base does not provide an objective simulation of the real world. 
Rather, visual and motion (kinesthetic) sensations work together to provide 
a subjective simulation of the real world, as perceived by the crew. Visual/ 
motion response should then be evaluated in terms of a "perceptual figure 
of merit" based upon such factors as their synchronization with each other, 
and correct initial response to the onset of an aircraft maneuver. 

The bulk of this evaluation must of necessity be done in integrated 
operation. Initial validation and "tuning" of the software can be done using 
a simple linearized simulation of the motion-base .hardware, comparative plots 
of vehicle and motion-base displacements, rates and accelerations, and 
automatic evaluation using a perceptual figure of merit. 
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FIGURE 2-16. SYNERGISTIC MOTION-BASE CONFIGURATION 
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FIGURE 2-17. MOTION-BASE SOFTWARE INTERFACES 
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TABLE 2-8. MOTION-BASE DRIVE MODULE PARAMETERS 


SYMBOL 

DESCRIPTION 

TYPE 3 

V.e.y 

Vehicle Euler angles 

I 

to 

Vehicle angular-rate vector 

'I 

a 

Vehicle acceleration vector 

I 

- 

Hardware gains, lags, limits, etc. 

I 

- 

"ideal" actuator commands 

P 

— 

actuator-displacement feedback signals 

I 

t . . 

real actuator commands 

CP 


a Legend: I = input 

P = performance parameter 

CP= critical performance parameter 
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2.4 VEHICLE CONFIGURATION MODULES 

The Shuttle vehicle undergoes discrete configuration changes compatible with 
each mission phase. Those simulation modules which are dynamically affected by 
configuration discretes are described in this section. These modules include 
Aerodynamics, Aerothemiodynamics , and Mass Properties. 

2.4.1 Aerodynamics 

This section describes a reference module and an approach to be used in the 
verification of simulation aerodynamics modules. The technique presented provides 
verification of the aerodynamic force and moment calculations and the selection 
logic that defines the flight regime and vehicle configuration dependency. 
Verification of the simulation aerodynamics data base (i.e., the stored data tables) 
is out of scope of this study and the assumption is made that the tabular data has 
been previously verified. 

Consideration is given only to the Shuttle vehicle aerodynamic forces and moments; 
however, the basic approach can be extended to include hinge moment calculations, 
the aerodynamic force and moment calculations for the separated solid rocket boosters 
and external tank, and to any other aerodynamic calculations. 
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2. 4. 1.1 Aerodynamics Reference Module Description 

The reference module and the approach presented will provide data necessary 
for verification of simulation aerodynamics modules with respect to their cal 
culation of the aerodynamic forces and moments that are sent to the equations 
of motion. The data provided consists of aerodynamic forces and niom cnts ^ 
the full range of flight regime and vehicle configuration options. Modeling for 
the reference module is based on the Space Shuttle vehicle; however, module 
generalizations and the basic approach can be easily applied to other vehicles 


Aerodynamic modules can in general be broken into three major sections* 

1) the logic and service routines necessary to retrieve the appropri ate aerQ 
dynamic data from the tables, 2) the calculations necessary to compute the body 
axis forces and moments, and 3) the arrays containing the tabulated aerodynamic 
data. The verification techniques with the reference module presented apply 
only to the first two sections. It does not appear to be within the S co pe 0 f 
this study to provide for the verification of stored data, and the assumption 
is made that all aerodynamic data tables have been previously verified We 
anticipate that some project-level machinery will be employed for updati ng and 
validation of the "master" aerodynamic data file (i . e. , the reference data tapes 
discussed In Referenced) . Also "customized" data files for individual simula- 
tors will probably be extracted from the master file by automated techniq Ue$ . 
e.g., the use of program MOPAS (Matrix Oriented Production Assembly Sy s tem ) 
Differencing techniques could be utilized for the verification of tabula r d ata 
and would be directly applicable to data verification for the individual 
simulators. These techniques will be discussed in a future report. 


The reference aerodynamic force and moment data is provided per indicated 
vehicle configuration and flight conditions. The major vehicle conf i gura ti . Qn 
change options are the three usual arrangements (1) Orbiter plus externa] tank 
(ET) plus solid rocket boosters (SRBs),(2) Orbiter plus ET, and (3) Qrbite r alone 

! Rm«)DUCiI-I T .jTY r*r 

ORIGINAL i'A*U£ :? . ' 
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"Incremental effects" per indicated aero-surface positions, landing gear 
deployment, or drag chute deployment provide minor deviations in the vehicle 
configuration. Flight conditions include the relative wind conditions, the 
vehicle body rates, and the relative conditions between the vehicle and the 
ground/FT, or SRBs as appropriate to define ground/proximity aerodynamic 
effects during landing and separation respectively. 

The online data arrays from which appropriate aerodynamic data is retrieved 
are initialized per the indicated vehicle configuration from a reference aero- 
dynamic data file. In addition to these aerodynamic tables, data base require- 
ments include the aerodynamic reference center-of-mass and the vehicle reference 
characteristics {mean aerodynamic chord (c), lateral reference length (b), and 
the aerodynamic reference area (s ) ) . 

From an overview the reference module would replace the call to CHKMOD in 
the generalized verification executor, SOFCHK, presented in Figure 2-1 of this 
report. Check point data required to drive both the simulation module and the 
reference module would be provided by an appropriate checkpoint generation 
routine as is also indicated in Figure 2-1 of this report. The required check 
point data is discussed in section 2. 4. 1.3. 

Table 2-9 presents the parameter list for the reference module and Figure 2-18 
presents the corresponding math flow. 

2. 4. 1.2 Aerodynamics Module Verification 

The usual approach taken with respect to aerodynamic equation formulation 
is to model the "clean" vehicle with additive incremental effects due to devia- 
tions from the "clean" configuration (e.g., effects due to positioning of aero- 
surfaces, landing gear deployment, or drag chute deployment) or deviations from 
a free stream air flow (e.g., effects due to proximity of the SRBs, the ET, or 
the ground) . 

The need for modeling of individual effects and the related fidelity will 
in general vary from simulation to simulation. The respective verification 
task for each simulation dictates the use of a reference module of fidelity 
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TABLE 2-9. AERODYNAMICS REFERENCE MODULE PARAMETER LIST 


PARAMETER 

DEFINITION 


CONFIGURATION 

VEHICLE CONFIGURATION IDENTIFIER ( INDICATES 
ORBITER+ET+SRBs , ORBITER+ET, or ORBITER) 

I 

FLIGHT PARAMETERS 

M-MACH NUMBER, a-ANGLE-OF-ATTACK, 3-SIDESLIP ANGLE, 


(M,a,0,V/\,q.) 

Va-VEHICLE VELOCITY RELATIVE TO AIR MASS, ^-DYNAMIC 
PRESSURE 

I 

BODY RATES (p,q,r) 

VEHICLE ANGULAR RATES (p-ROLL, q-PITCH, r-YAW) 

I 

RELATIVE CONDITIONS 
(GROUND, PROXIMITY) 

RELATIVE CONDITIONS BETWEEN VEHICLE AND GROUND NECESSARY 
TO MODEL GROUND EFFECTS, RELATIVE CONDITIONS BETWEEN 
VEHICLE AND SEPARATED SRBs OR ET NECESSARY TO MODEL 
PROXIMITY EFFECTS 

I 


AERO-SURFACE 

6R-RUDDER POSITION, 6SB-SPEED BRAKE (FLARED RUDDER) 


POSITIONS (6R.6SB, 

POSITION, 6A-AILERON POSITION, 6E-ELEV0N POSITION, 

I 

iSA,6E,6BF) 

6BF-BODY FLAP POSITION 


LANDING GEAR AND 

DLG-LANOING GEAR INDICATOR FOR DEPLOYED/RETRACTED STATUS 

I 

DRAG CHUTE INDICA- 

DCHUTE-DRAG CHUTE INDICATOR FOR DEPLOYED/NOT DEPLOYED 


TORS (DLG, DCHUTE) 

STATUS 


CENTER-OF-MASS 

CENTER-OF-MASS LOCATION IN VEHICLE BODY COORDINATE 

I 

^ X CG ,Y CG ,Z CG^ 



AERO TABLES 

TABULAR AERODYNAMIC DATA STORED AS FUNCTION OF ONE TO 
SEVERAL VARIABLES (DIFFERENT FOR EACH OF THE VEHICLE 
CONFIGURATIONS) 

I 

REFERENCE CENTER-OF- 

AERODYNAMIC REFERENCE CENTER-OF-MASS CORRESPONDING TO 

I 

M*,SS (X CG , Y cg , 

z cgW 

DATA IN THE AERO TABLES 


VEHICLE CHARACTER- 

t-HEAN AERODYNAMIC CHORD, b-LATERAL REFERENCE LENGTH, 

I 

ISTICS (c, b, s) 

s-AERODYNAMIC REFERENCE AREA 


FORCE COEFFICIENTS 

TOTAL AERODYNAMIC FORCE COEFFICIENTS REFERENCED TO THE 

P 

(CX, CY, CZ) 

BODY AXIS SYSTEM 


MOMENT COEFFICIENTS 
( C1 AC . Cm AC , Cn AC ) 

(C1 TC , Cm TC , Cn TC ) 

AC-TOTAL AERODYNAMIC MOMENT COEFFICIENTS ABOUT THE 
AERODYNAMIC CENTER-OF-MASS , TC -TOTAL AERODYNAMIC MOMENT 
COEFFICIENTS ABOUT THE TRUE CENTER-OF-MASS 

P 

CY POWER 
™ BASE 

POWER-ON BASE AXIAL FORCE 

P 

FORCES 

AERODYNAMIC FORCE COMPONENTS IN THE BODY AXIS SYSTEM 

CP 

(FX. FV. FZ) aerq 



MOMENTS 

AERODYNAMIC MOMENTS ABOUT THE TRUE CENTER-OF-MASS 

CP 

(MX, MY, MZ) aerq 




P - PERFORMANCE PARAMETER 

CP - CRITICAL PERFORMANCE PARAMETER ■ ll ,n. il nr 

I - INPUT * I A. I, J3 POOR 

2-58 

MCDO/V/VCLt OOUOL4S /JSrnOM/lOr/CS COMP>»/VV*C4Sr 


r 





MDC Ell 27 
1 August 1974 



FIGURE 2-18 AERODYNAMIC REFERENCE MODULE 
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greater than or equal to that proposed for the simulation module. (Simulation 
modules of less fidelity than the reference are not expected to match exactly, 
but verification can be accomplished through output data comparisons and 
engineering judgement.) Instead of attempting to identify the maximum simula- 
tion requirements and then developing a reference module of appropriate fidelity, 
the generalization is made to require that the reference module reflect the 
maximum fidelity available. Since the maximum fidelity for an aerodynamic 
model is determined by the availability of aerodynamic data, the approach pre- 
sented is to utilize the reference aerodynamic data file as the data base and 
to use the aerodynamic equation formulations of the aerodynamic group (vehicle 
vendor or designated subcontractor) providing the data implemented on the 
reference file. 

The math flow presented in Figure 2-18 indicates the simple structure suggested 
for the reference module. At the beginning of a check sequence the table arrays 
are initialized with the appropriate data per the indicated configuration; If 
any configuration changes are made in the course of a run, the reference module 
table arrays are re-initialized with the newly appropriate values, All force 
and moment calculations are the same for all combinations of configuration and 
flight regime. The equations represent the most general case with non-applicable 
effects zeroed either v.ough aerodynamic data returned from table interpolations 
or through input variable specifications. 

The generalized functions appearing in the math flow should be replaced 
with appropriate equations obtained from the vehicle aerodynamics reference 
source as previously discussed. The independent variables of the functions are 
indicative of the effects to be modeled. The addition or deletion of effects 
may be necessary or required per simulation requirements and consequently the 
reference module equation development should be coordinated with personnel 
defining simulation requirements and personnel performing aerodynamics studies. 
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Implicit in the generalized functions shown for generation of the total 
coefficients is a series of table look-ups for retrieval of appropriate data. 

The table searches and interpolations will involve from one to three or even 
four variables. Service routines necessary to perform these functions are also 
a part of the reference aerodynamic module in the sense that they define a 
particular retrieval technique and thus an associated accuracy for returned data. 
An explicit verification for the counterpart table searches and interpolations 
of the simulation module is not provided. However, verification of the simula- 
tion service routines is provided indirectly through comparison of the output 
performance parameters. 

The equations used to generate total body axis forces and moments from the 
previously computed coefficients assume a body axis system with "x" out the 
vehicle nose, "y" out the right wing, and "z" completing the right hand system. 

The vehicle body axis attitude rates and the aerodynamic moments have a positive 
sign convention consistent with a right hand system definition; sign conventions 
for control -surface deflections must be incorporated in the generalized functions. 

Performance parameter data generated for comparison purposes consists of 
the body axis forces and moments and corresponding total force and moment aero- 
dynamic coefficients; which are output to a data file for each check point. 

Post processing of the output data is discussed in the following subsection. 

2. 4. 1.3 Verification Check Data 

Check point Input data for both the reference and the simulation modules 
should be generated and exist in storage for extraction by the check point 
generation routine. The complete sequence of check points should exercise all 
capabilities for each configuration and also exercise all possible transitions 
between configuration. 

The suggested ap y 'oach is to subdivide the check sequence into sub-sequences, 
each of which contains sequential check points over a "range of vehicle states" 
for a given flight regime. The individual "ranges of vehicle states" can then 
be chosen to exercise all vehicle configuration and flight regime combinations. 

The appropriate input parameter values for the check points can then be gener- 
ated off-line by digital analysis programs an'd' stored in arrays by subsequence 
to be retrieved as appropriate by the check point generation driver routine. 
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The spacing of check points within an individual "range of vehicle states" and 
the spacing between the individual "ranges of vehicle states" is arbitrary and 
the only requirement is to include enough checkpoints pe*' subsequence to provide 
a comparison plot for that particular subsequence. 

In addition to the standard sequence of check points described above, the 
reference module can be easily driven by data generated in a previous simulation 
run. This provides a capability to verify the simulation aerodynamic perform- 
ance in simulation situations suspected of possible inaccuracies. 

The verification of the simulation aerodynamic performance can be handled 
the same as that for most other modules, namely by engineering judgement applied 
to comparison plots generated by post processing of output from the simulation 
and the reference modules. 


2. 4. 1.4 Reference Module Requirements 

The required data base items for the reference module include the tabular 
aerodynamic data and the corresponding reference characteristics of the vehicle. 
Reference aerodynamic data files (Reference 14) are available and can be used 
for the reference module aerodynamic table initializations. The corresponding 
vehicle reference characteristics are available from the aerodynamic data 
documentation used in development of the reference data files (e.g., the Aero- 
dynamic Design Data Book as referred to in Reference 14). 

In addition, since equations for computing the total coefficients must be 
consistent with available data, the suggestion is to use equation formulations 
from the provider of the reference data available on the data tapes (i.e., the 
vehicle vendor). The vehicle vendor (or designated subcontractor) will have 
detailed aerodynamic models for use in design studies and the reference module 
model development can be reduced to a coordination effort by using these avail- 
able vendor models. 
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2,4.2 Aerothermodynami cs 

This section discusses the functions and verification of the 
software module required to simulate the aerodynamic heating incurred 
by the Orbiter during entry and ascent. The Orbiter Thermal Protection 
System (TPS) is used to dissipate the heat flow due to aerodynamic 
heating. This prevents the primary aluminum structure from exceeding a 
temperature of 350° F (Reference 20 ). The baseline TPS consists of 

reusable surface insulation tiles bonded to the primary orbiter structure, 
as shown in Figure 2-19 (Reference 10). 

The aerodynamic heating module will provide inputs to crew displays 
for the purpose of monitoring 14 critical bondline temperatures as shown 
in Figure 2-20 . The crew display method is via select CRT (Reference 22). 

Bondline temperatures will be computed by the aerothermodynamics 
simulation module and the results used for crew display, post-simulation 
analysis, and simulator module verification. The computed bondline 
temperatures will simulate readings taken by bondline thermocouples as 
depicted in Figure 2-21 . The heat rate into selected orbiter compartments 
will also be computed as an input to the Active Thermal Control Subsystem 
(ATCS) module. Figure 2-22 shows' the interaction between the 
aerothermodynamics module and other orbiter systems simulation software 
modules. Figures 2-23and 2-24 describe the data flow through the 
aerothermodynamics module. 
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FIGURE 2-19. ORBITER THERMAL PROTECTION SUBSYSTEM 
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FIGURE 2-23. AEROTHERMODYNAMICS FLOW DIAGRAM 
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FIGURE 2-23. CONTINUED 
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FIGURE 2-24. AHEAT FLOW DIAGRAM 
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2.4. 2.1 Aerothemiodynamic Module Description and Performance Parameters 

This module is used during entry and ascent mission phases to evaluate 
the skin temperature and the conducted heat to the bondline. These results 
are used in the bondline temperature calculations. Structure temperatures 
at a total of 181 orbiter locations ar p recorded during a mission; however, 
only 14 bondline temperatures are crew monitored and utilized to provide 
flight dynamics Information (Reference 21 ). These results are considered 
critical performance parameters for the training simulator. The performance 
parameters listed in Table 2-10 were selected using the criteria developed 
In section 2.1.1 . 

2. 4. 2. 2 Entry Aerothermodynamics Simulation 

During portions of the entry mission phase, it is necessary to operate 
the orbiter near its maximum heat loading to obtain maximum downrange position 
A total of 24 surface points will be used in describing the vehicle surface 
for temperature measurement purposes. For a given angle of attack, oC, the 
surface temperature at a discrete point on the vehicle surface, due to 
aerodynamic heating can be computed using the equation (Reference 16 ): 

T s - 

fh. ~ atmospheric density 
V = vehicle velocity 
T s = Temperature 

This relationship is based upon empirically determined values of k, x, and y. 
These constants can be arrived at through the use of test data and curve fit 
equations. It has been estimated that, for each point selected on the orbite 
surface, values of k, x, and y for 5 V's and 4«'s should provide sufficient 
accuracy. Linear interpolation will be used for points between the tabular 
values. 

The i.eat flow rate due to aerodynamic heatinq will be determined throuqh 
the use of test data in an empirical relationship (Reference 24 ). The 
relationship is based upon vehicle velocity, atmospheric density, dynamic 
pressure, angle of attack, and surface area: 
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Table 2-10. 

PERFORMANCE PARAMETERS AND COEFFICIENTS 


SYMBOL 

PARAMETER DESCRIPTION 

USE 9 

T S 

Surface Temperatures (24) 

P 

Tb 

Bondline temperatures (14) 

CP 

Q'a 

Surface heat rates (24) 

P 

Qc 

Conducted compartment heat rates 

P 

Qr 

Radiative compartment heat rates 

P 

Tc 

Compartment wall temperatures 

P 

A 

Surface area of selected sections (24) 

I 

B 

Bondline temperature measurement locations 

I 

X 

Material thicknesses 

I 

K m 

Material thermal conductivities 

I 


Material densities 

I 

c „ 

£ 

Material specific heats 

I 

Material emissivities 

I 

Cr 

Constants of black body radiation 

I 

k,x,y 

Surface temperature related empirical constants 

I 

V 

Vehicle velocity 

I 

q 

Vehicle dynamic pressure 

I 


Vehicle angle of attack 

I 

/°a 

Atmospheric density 

I 


a 

P - Performance parameter 
CP - Critical performance parameter 
I - Input 


2-73 

MCOO/VA/ITU- D017GL4S ASTWO/V/ltvr/CS CO/VfP4/VV» C4ST 






MDC El 127 
1 August 1974 


55 f (V.^.q, c-i ,A). 


V « vehicle velocity 

n = heat transfer rate due to aerodynamic 
*a 

heating 

/°<x ~ atmospheric density 
q = dynamic pressure 
ot = angle of attack 
A = surface area of section 

Curve fit equations will be generated using test data to determine Q a . 
The outer surface of the orbiter will again be divided into 24 sections. r 
different equation will then be applied to each section to determine Q a . 

The temperature at the bondline can now be determined using the surface 
temperature inputs and heat flow rates due to aerodynamic heating. These 
temperatures can be found by solving the general heat conduction equation 
applied to each section, the general form being (Reference 15 ): 

Qc = K m A AT/AX 

Where: 

Q = conducted heat transfer rate, per unit of 
c 

time, due to aerodynamic heating 

K = thermal conductivity of the material 
m 

A = area normal to the heat flux 
AT = temperature difference between the 
bondline and vehicle surface 
AX = thickness of the material normal to the 
heat flux 
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The steady-state temperature at the bondline is then in this case, 
calculated to be: 

\ “ T s - c A x/ a) 

Where: 

Tjj = bondline temperature 

T = surface temperature 
* ^ 

Q c A, X as previously defined 

Partial modification of the general equation may be necessary in 
specific sections to include more than one dimension of heat flow. 

Provision must also be made to allow for variations in the values of 
thermal conductivity as it is both temperature and pressure dependent 
for some materials. The bondline temperature will then be stored for 
output to crew display, analysis, and/or software module verification. 

If those steady-state approximations Jo not provide acceptable 
accuracy for training purposes, it will be necessary to numerically 
solve the general heat conduction equation: 

<JT/ <)t - T/c>X ) 

Where: 

T = temperature of the material 

t = time 

K w - thermal conductivity 
material density 

Cm= specific heat 

x = distance at which the temperature is 
evaluated 

The quantity of heat transferred, due to aerodynamic heating, into 
other orbiter compartments will be computed in conjunction with compartment 
wall temperatures to provide inputs to the ATCS module. These parameters 
may be evaluated by applying an equation similar to the one used in the 
bondline temperature calculation. This equation will be applied to each 
layer of material until the compartment walls are reached. 

2-75 

MCDONNELL DOUGLAS ASTRONAUTICS COMPANY - EAST 


■ *«4 • »*****■*« 


MDC Ell 27 
1 August 1974 


The general, steady-state heat conduction equation for one 
surface is then; n 

Q c = AAT/g (AX, A..) 
for: 1=1, 2, 3, ...n 

where: n = number of layers of material 

Q c » A, T, X, K„, as previously defined 

The heat rate per unit area radiated from the wall into the 
compartment is then expressed by the relationship (Reference 15 ): 

Vr C. t c 4 

Where: 

= heat rate per unit area radiated 
into the compartment 
£ = emissivity 

C r = constant of black body radiation 
T c = compartment wall temperature 

Again, this equation may require modification to allow for 
multidimensional heat flows and ompartment wail interaction. The 
relationship only describes the radiative contribution of heat to the 
inner compartment due to aerodynamic heating. 

2. 4. 2. 3 Ascent Aerothermodynamics Simulation 

The ascent phase aerothermodynamics computations will use the same 
equations as the entry phase, however, the table structure will differ: 

(a) The ascent tables will require fewer angle of attack points, 
since the angle of attack varies less during ascent than entry. 

(b) The ascent tables will provide heating coefficients for all 
three ascent configurations: Orbiter/ET/SRB ‘s , Orbiter/ET, and 
Orbiter alone. 
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Considering the empirical equation for orbiter surface temperature; 

T s - k^V 

it is estimated tha t * for each angle of attack, empirical values of k, x, 
and y will be needed at 5 V 1 s for each of the discrete surface points of interest. 
Thus, storage requirements for this table in the ascent, software module would 
be less than the storage required for the entry phase table. 
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2. 4. 2. 4 Aerothennodynamics Module Verification 

The simulation module will be driven by a support software routine 
which will receive inputs to be passed (via common, argument list, and/or 
block data) to the simulation module. These inputs include parameters 
such as aerodynamic data tables and flags to indicate the mode in which 
the module is to be exercised. The driver will also indicate the input/output 
requirements of the simulation module. These requirements include training 
simulation (real-time), post simulation analysis, and software module 
verification. The software module will be exercised at a rate of one 
execution per second to provide output parameter updates. 

Verification of the simulator software module will be accomplished 
using suitable test data and verification techniques. One suitable means 
of verification would exist in the construction of a data file containing 
special check points of known values. The module could then be exercised 
and the results compared with test and design data. The data points 
selected as check points would include not only values upon which empirical 
constants are based, but also points in between for which results are known. 

The software module can be exercised with step inputs and special 
reference trajectories. By holding one particular variable constant, for 
example heat load, the other parameters can be calculated and compared with 
off-line computations. 

Special reference trajectories to be used in the verification of the 
software module might be the same as those found in References 17,18 and 
19 . The trajectory variables would be input to the software module and 

the module computed results compared with similar results found in the test 
and design data found in the references. The reference trajectories will 
simulate all configurations during entry and ascent, thereby exercising all 
options required for software module verification. 
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Trajectory tapes generated by other engineering analysis programs 
(Reference 23 ) incorporating an aerodynamic heating module may also 
be used in a verification technique. The same trajectory would be 
utilized with the simulation module and the engineering analysis program. 
Their respective results could then be compared. This would require the 
use of a special driver routine to read and reformat the data tape for use 
with the simulation module. 

For some parameters, off-line calculations might be necessary to 
evaluate the results in proper perspective as the parameters .alculated 
in each module might not be exactly equivalent, but would be related. 
Engineering judgement would have to be implemented to determine conversion 
methods and accuracy criteria for module verification. 


2.4,3 Mass Properties 

This section describes the Shuttle mass properties simulation 
software module. Simulation and verification of the Shuttle mass 
properties module will be required for ascent, on-orbit, and entry 
mission phases. The software routine will simulate changes in vehicle 
gross weight, center of mass, and inertia tensors. 

A general inertia tensor is conveniently depicted as. a symmetric 
three-by- three matrix, as follows: 
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Inputs to the mass properties simulation software include 
(Reference 16): 

- propellent remaining (ME, OMS, etc.) 

- mission type 

« configuration discretes 

- payload 

- mission extension kits if any 

The outputs of the mass properties simulation software will consist 
of: 

- vehicle gross weight 

- vehicle center of mass location 

- vehicle inertia tensor 

These output parameters will provide inputs to the vehicle equations 
if motion (EOM) and/or module verification procedures. The interaction 
between the mass properties simulation module end other systems simulation 
modules is shown in Figure 2-25. The performanc parameters described in 
Table 2-11 were selected using the criteria de. ■ ■>ed in section 2.1.1. 

2. 4. 3.1 Mass Properties: Ascent 

In the ascent mission phase, the Shuttle vehicle mass properties will 
involve the Orbiter plus the solid rocket boosters (SRB) and external tank 
(ET). The factors having the greatest dynamic influence on mass properties 
are then (ReferencelG) : 

- solid rocket propellent remaining 

- external tank fuel/oxidizer remaining 

- CMS fuel /oxidizer remaining 

- solid rocket separation 

- external tank separation 
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TABLE 2-11. MASS PROPERTIES MODULE PARAMETERS 


PARAMETER DESCRIPTION 

TYPE a 

Orbiter vehicle mass (less fuel/oxidizcr) 

I 

Orbiter vehicle mass center (less fuel /oxidizer) 

I 

Orbiter vehicle inertia tensor (less fuel/oxidizcr) 

I 

External tank mass (dry) 

I 

External tank mass center (dry) 

I 

External tank inertia tensor (dry) 

I 

SRB mass (empty) 

I 

SRB mass center (empty) 

I 

SRB inertia tensor (empty) 

I 

P/T vehicle mass (less fuel/oxidizer) ^ 

I 

P/T vehicle mass center (less fuel/oxidizer) 

I 

P/T vehicle inertia tensor (less fuel/oxidizer) 

I 

MPS fuel /oxidizer masses 

P 

MPS fuel /oxidizer mass center 

P 

MPS fuel /exi J:-er inertia tensor 

P 

SRB propellant mass 

P 

S r .U propellant mass center 

P 

jRB propellant inertia tensor 

P 

OMS fuel/oxidizer masses 

P 

OMS fuel /oxidizer mass center 

P 

OMS fuel/oxidizer inertia tensor 

P 

RCS fue I/oxidizer masses 

P 

RCS fuel/oxidizer mass center 

P 

RCS fuel/oxidizer inertia tensor 

P 

P/T fuel/oxidizcr masses 

P 

P/T fuel/oxidizer mass center 

P 

P/T fuel/oxidizer inertia tensor 

i 

Shuttle vehicle (total) mass 

CP 

Shuttle vehicle (total) mass center 

CP 

Shuttle vehicle (total) inertia tensor 

CP 


P/T denotes payload/target a Legend: 

P = Performance Parameter 

1 = Input 

CP= Critical Performance Parameter 
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These inputs will enable the mass properties simulation software 
to compute outputs based upon information selected from performance 
data tables composed of: 

- ascent configuration 

- mass of fuel/oxidizer remaining 

- time since SSME and/or SRB ignition 

- fuel /oxidizer mass position 

- inertia tensors of shuttle component masses 

As shown in Figure 2-26 , outputs from the mass properties simulation 
software will be updated 10 times per second during ascent. 

2. 4. 3. 2 Mass Properties: On-Orbit 

Orbital insertion initiates the on-orbit phase of the mass properties 
simulation software. During on-orbit the Orbiter mass properties are 
affected by: 

- RCS fuel/oxidizer remaining 

- OMS fuel/oxidizer remaining 

- mission type 

- payload/target (P/T)intoraction 

The amount of maneuvering required of the Orbiter during the on-orbit 
phase will affect the OMS/RCS fuel /oxidizer us:ge. This will require that 
updates based upon these parameters be performee dynamically as fuel/oxidizer 
is consumed. A larger consumption rate will occur during rendezvous or P/T 
docking/attachment. 

Payload/target influences upon the orbiter mass properties are dependent 

upon: 

- P/T type (propulsive or non-propulsi ve) 

- P/T position in the payload bay 

- P/T attachment/docking 

- P/T rendezvous 
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An attachment/docking or rendezvous boolean will be used to 
indicate the respective mode. Attachment/docking or rendezvous 
necessitates that mass properties updates be made at a rate of 10 
times per second as shown in Figure 2-2G. Other on-orbit mooes require 
an update of once per 2 seconds (Reference 24). 

Upon attachment/docking, the P/T is assumed integral with the 
Orbiter. Its mass properties must then be computed and combined with 
those of the Orbiter. Figure 2-27 shows the P/T mass properties flow 
diagram. 


The orientation of the P/T will influence its contribution to the 
Orbiter mass properties during attachment/docking. The P/T inertia 
tensor must be first rotated to at. Orbiter parallel axis as follows 
(Reference 25 ): 


I 

op 



R 


T 


Where: * P/T inertia tensor in an orbiter 

op ' 

parallel axis 

*P/T - P/T inertia tensor about P/T axis 
through its mass center (C.M.) 

R = rotation matrix 


The parallel axis theorem can now be employed to transform the P/T 
inertia tensor to a P/T inertia tensor about the Orbiter centered axes. 
Applying the parallel axis theorm from Reference 26 : 


I 


oc 


! P/T + M P/T 


D 


2 


Where: 

Iqc c inertia tensor component of the P/T about the 
orbiter centered axes 


Ip/y- as previously defined 
M = mass of the P/T 

D = perpendicular distance from Orbiter inertia 
tensor axis to Ip^j tensor axis 
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The P/T inertia tensor can now be combined with the orbiter vehicle 
inertia tensor about the corresponding axis. 

2. 4. 3. 3 Mass Properties: Entry and Aerofl'ight 

Mass properties during the entry and aeroflight phases are dependent 
upon the following: 

- payload type 

- payload position in payload bay 

- OMS fuel/oxidizer residuals 

- RCS fuel/oxidizer remaining 

Payload mass properties will be constant and non-updating during this 
phase. The overall mass properties variations during this phase will be 
small. These variations will be based upon the amount, of OMS/RCS fuel/ 
oxidizer consumed during de-orbit burn and attitude control in entry. 

The aeroflight phase uses small amounts of RCS thrusting for yaw 
control. The minor changes in mass properties occuring in the entry and 
aeroflight phases require the mass properties simulation software module 
to provide updates •: l a rate of once per 2 seconds. 

2. 4. 3. 4 Module Verification 

Verification of the Shuttle mass properties simulation software can be 
accomplished through the use of various techniques. One method of verification 
would utilize specialized input data points in a reference file. This data 
would provide fixed amounts of fuel/oxidizer remaining for all mission phases 
and vehicle configurations . The Shuttle mass properties parameters could then 
be evaluated with this data using the simulation module and the results checked 
with off-line calculations. Suitable accuracy criteria, developed using 
engineering judgement and test data, would provide validation standards. 

Another verification technique can be implimented using other engineering 
analysis programs as described in Reference 23 . The same data could be input 
to the engineering analysis program and the simulation software module. Their 
results would then be compared. This method might be more difficult to impliment 
than that previously discussed since the test data would have to be constructed 
for input to both programs. 
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2.5 VEHICLE DYNAMICS MODULES 

This section briefly describes the Shuttle vehicle dynamics simulation 
modules and their interfaces with other simulation modules. Validation 
methods, and data sources are also discussed. References 24 and 27 provided 
much of the basic information for this section. 

Table 2-12 shows the hierarchy of simulation modules under the Vehicle 
Dynamics category. Mechanical subsystems per s_e (v.l.l.n) will be discussed 
in detail in a later report. This report is concerned only with the vehicle 
dynamic aspects of mechanical subsystems: i. e., the reaction forces and 
moments which they exert upon the Shuttle vehicle. 

Figure 2-28 provides an overview of the interfaces among the simulation 
modules involved in vehicle dynamics. The translational and rotational 
equations of motion (EOM) modules use force and moment, mass and inertia inputs 
to compute vthicle state variables, both absolute (Shuttle vehicle) and relative 
(multiple-body). Forces and moments come from gravity, aerodynamics, propulsion, 
venting, and mechanical -subsystem modules ; mass, inertias, and c.g. position are 
provided by the mass-properties module. Bending and slosh dynamics produce 
additional body forces and moments; they also affect the apparent angles, rates 
and accelerations sensed by the avionics. Finally, the avionics modules provide 
commands to propulsive systems and control actuators, while power subsystems 
modules provide any required electrical and hydraulic power. 

Simulator hardware interfaces of interest, not shown on this figure, include 
the visual and motion systems, which are driven by translational and rotational 
dynamics, and the instructor/operator station, which allows insertion of simulated 
faults into vehicle subsystems simulation modules. 

Table 2-13 provides an integrated list of parameters for all vehicle 
dynamics simulation modules. 
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TABLE 2-12. VEHICLE DYNAMICS (V.3) SIMULATION MODULE HIERARCHY 


V.3.1 RIGID-EODY EQUATIONS OF MOTION 

V.3. 1.1 Translational EOM 
V.3. 1.2 Rotational EOM 
V.3. 1.3 Multiple-Body EOM 

V.3. 2 MECHANICAL-SYSTEM DYNAMICS 

V.3. 2.1 Landing/Deceleration Dynamics 
V.3. 2. 1.1 Landing Gear 
V.3. 2. 1.2 Drag Parachute 
V. 3.2.2 Docking Dynamics 
V.3. 2. 3 Separation Dynamics 
V.3. 2. 3.1 ET/SRB Separation 
V.3. 2. 3. 2 Orbiter/ET Separation 
V; 312.4 Actuation-Mechanism Dynamics 
V.3.2.5 Payload Deployment/ Retrieval Dynamics 

V.3. 3 BENDING & SLOSH DYNAMICS 

V. 3.3.1 Body Bending Dynamics 
V.3. 3.2 Fuel Slosh Dynamics 
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TABLE 2-13. VEHICLE DYNAMICS SIMULATION PARAMETERS 


SYMBOL 

DESCRIPTION 

TYPE 3 

- F g 

gravitational force, in 
F.CI axes 

I 

C 

-mech 

mechanical-system reaction 
forces in body axes 

I 

- F a 

aerodynamic force, in 
body axes 

I 

Ep 

propulsive forces, in 
body axes 

I 

E, 

venting forces, in body 
axes 

I 

-9 

gravity-gradient moment, 
in body axes 

I 

-mech 

mechanical -system reaction 
moments, in body axes 

I 

- L a 

aerodynamic moment, in body 
axes 

I 

h> 

propulsive moments, in body 
axes 

I 
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SYMBOL 


M. M n 
t p 


it. ip 



r,v,a 


<P,&> V 


CO o(. 


Sto, 


DESCRIPTION 


venting moments, in body I 
axes 

vehicle mass I 

target, payload mass 1 

vehicle inertia tensor, I 

in body axes 

target, payload inertia I 

tensor 

center-of-gravity po: itiion I 
in body axes 

vehicle position, velocity CP 
and acceleration vectors 

two-body relative position, CP 
velocity, and acceleration 
vectors 

vehicle direction cosines P 

vehicle quaternion P 

parameters 

vehicle euler angles CP 

vehicle angular rate and P 

angular acceleration vectors 

two-body relative euler CP 
angles 

two-body relative angular P 
rate and accleration 

i • 

vectors 
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SYMBOL 

DESCRIPTION 

TYPE 3 

A(config) 

configuration-change 

I 


flags (Orbiter/ET/SRB's, 
Orbiter/ET, Orbiter) 

I 

A (fuel) 

fuel consumed (ME and OMS) 

I 

Si,^ 

damping and frequency for 
bending & slosh modes 

I 

«« 

generalized forces for 
bending & slosh equations 

P 


generalized coordinates 
(normal modes) for bending 
& slosh 

P 


bending & slosh sensitivity 
functions (mode shapes); 
functions of longitudinal 
position 

I 

Eb, Es 

bending & slosh forces, in 
body axes 

CP 

L h L 
-b, -s 

bending & slosh moments, in 
body axes 

CP 

A y*s A 



apparent euler angles at na 
base 

v CP 

A 



U3 

apparent body-axis angular 

CP 


rates at rate-gyro location 

► 

A 

a 

apparent body-axis sensed 

CP 


accelerations at accelerome 
locations 

;er 


a. 

Legend: I = input 

P = performance parameter 
CP = critical performance parameter 
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2.5.1 Rigid-Body Equations of Motion 

These modules compute Orbiter vehicle translational and rotational state 
variables during all mission phases. During certain mission phases, 
equations of motion must simultaneously be solved for one or more bodies other 
than the Orbiter: Boeing 747 launch aircraft, separated SRB's or ET, 

rendezvous and docking targets, and payloads being deployed or retrieved by 
means of the Payload Deployment and Retrieval Subsystem (PDRS). 

2. 5. 1.1 Translational EOM 

Shuttle missions span several dynamical regimes, requiring different 
implementations of translational EOM. Table 2-14 briefly summarizes the modes 
of operation appropriate to each mission phase. Note that the Coordinate 
System(s) entry refers only to the coordinates in which the EOM are solved; a 
variety of other coordinate sets will also be in use for generation of auxiliary 
variables. Under Gravity Model, we do not attempt to specify which spherical 
harmonics will be used, nor how many, because the references are not in agreement 
on this point. Entries under Other Major Forces are selective, rather than 
exhaustive; e.g., additional on-orbit forces include atmospheric drag, RCS burns, 
and consumables venting. Finally, the two major EOM Formulations to be used 
are Cowell's Method {direct integration of all vehicle accelerations) and Encke's 
Method (integration of linear perturbations about a Kepler reference trajectory). 
Minor variations of these two basic methods will also be used during various 
mission phases. 

2. 5. 1.2 Rotational EOM 

Unlike translational EOM, rotational EOM are implemented in essentially 
the same manner for all mission phases, although not necessarily at the same 
iteration rate. The inertia tensor and all external moments will be expressed 
in body axes. Angular accelerations will be integrated in either direction-cosine 
or quaternion form (again, the references disagree); Euler angles and 
direction-cosine matrices will be available for use in other routines. 
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2. 5. 1.3 Multiple-Body EOM 

Multiple-body dynamical simulation is required at times during ascent* 
aerof light, and on-orbit operations. During on-orbit operations, simulation 
of near-, mid-, and far-distance regimes may be required. In the ascent and 
aeroflight phases, we do not anticipate multiple-body simulation requirements 
beyond the near-distance regime. Multiple-body computation will presumably 
be terminated v/hen the separating object (ET, SRB or launch aircraft) has 
departed from a predetermined "sphere of influence" centered on the Shuttle 
vehicle, beyond which recontact Is considered highly unlikely. For completeness, 
however, Table 2-15 indicates the computational modes appropriate to all 
combinations of distance regime and mission phase. 

Provisions must be made for designating either the target or the Orbiter 
as the origin of the relative coordinate system for simulation of rendezvous 
maneuvers in the mid-distance regime. 

In the near regime, the Orbiter and other bodies may interact through the 
medium of various Orbiter mechanical systems -- separation mechanisms, docking 
mechanisms, PDRS -- as discussed in section 2.5.2. Relative position and 
attitude variables will be used, in combination witi. simplified representations 
of the Orbiter and other-body geometry, to test for undesired contact between 
the Orbiter and the other body. 

2.5,2 Mechanical -System Dynamics 

We assume that each mechanical system listed in Table 2-12 will be 
simulated by an individual software module. Each such module will accept 
activation commands from the avionics and/or crew station, malfunction 
discretes from the instructor/operator station, and simulated electrical 
and/or hydraulic power from appropriate power supply and distribution modules. 
Internally, the simulation fidelity of these modules will vary from one 
simulator to another. Some mechanical activities may be simulated as 
Instantaneous actions, simple lags, or approximate transfer functions. Other 
systems may be simulated in high fidelity, with motors, valves, springs, dampers 
or whatever all represented as accurately as possible. These details will be 
discussed in later reports. 
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iTIONAL MODES FOR MULTIPLE-BODY EOM 


ON-ORBIT ASCENT AND AEROFLIGHT 


Independent 
(Cowell or Encke) 

Independent 

(Cowell) 

Relative 

(Encke or Clohessy- 
Wiltshire) 

Independent 

(Cowell) 

Relative 

(Gravi ty-grad'ient 
or uniform gravity) 

Relative 

(Cowell) 
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For this report, we are only concerned with the interactions between 
the mechanical -system modules and the vehicle translational and rotational 
dynamics — i.e., their reaction forces and moments on the Orbiter vehicle. 

These forces and moments will be provided in body axes, which requires each 
mechanical -system simulation module to !.'*ve access to body-axis geometry 
data: the direction cosines of the line of action of each reaction force, 
the point of application (where the mechanical system attaches to the 
Orbiter structure), and the current c.g. position. 

The discussion below briefly discusses the dynamical aspects of each 
subsystem of interest, using much-simplified figures for clarity. 

2. 5. 2.1 Landing/Deceleration Dynamics 
Landing Gear (LG) 

Landing gear drop (free-fall) produces a change in aerodynamics, but 
no perceptible forces or moments. 

Initial ground contact will occur with struts fully extended. As 
indicated by Figure 2-29 , vehicle altitude, attitude and geometry will determine 
which point on tlie Orbiter (hopefully one of the main landing gear) will 
contact the ground first; this will determine the instantaneous sign of the pitch 
and roll moments (from the impact) and the yaw moment (from tire/runway friction). 
The magnitude of the forces and moments will depend upon the Orbiter rates and 
accelerations, the simulated spring/damper characteristics of the LG, and the 
tire/runway friction coefficients. As the Orbiter bounces and/or settles onto 
all gears, strut dynamics, vehicle dynamics and aerodynamics will intimately 
interact. 

Main-gear braking. Fig. 2-30 » will produce retarding forces and pitchdown 
moments; differential braking and nose-gear steering will produce yaw moments. 
Tire/runway characteristics used to generate these forces and moments will 
probably be provided in table lookup or simplified functional form; e. g.„ NLG 
steering side force varies roughly as the sine of the tire slip angle. 
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FIGURE 2-29 . EXAMPLE REACTION FORCES AND MOMENTS FROM INITIAL 
GROUND CONTACT OF RIGHT MAIN LANDING GEAR. 



FIGURE 2-30 . EXAMPLE REACTION FORCES AND MOMENTS FROM NOSEWHEEL 

STEERING AND MAIN-GEAR BRAKING (ORBITER SEEN FROM 
ABOVE). 
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Drag Chute 

We assume that drag chute dynamics will not be modelled explicitly; 
rather, the chute-deployment flag will simply cause a change In vehicle 
aerodynaml cs . 

2. 5. 2. 2 Docking Dynamics 

Docking simulation {see Fig. 2-31 ) Is much similar to landing-gear 
ground contact simulation. Force and moment reactions will depend upon 
relative translational and rotational states, rates and Shuttle and target 
masses and Inertias, accelerations, as well as spring/damper response. 

Bounce-off and undesired Orbi ter/target contact are possible, and the 
simulation may Include enough detail to faithfully reproduce these phenomena. 
Alternatively, engineering analysis data may be used to define table-lookup 
regions of relative states and rates corresponding to successful and unsuccessful 
docking. When hard-aock is accomplished, the Orbiter and target will be 
merged into a single vehicle, as regards state variables, mass properties 
and aerodynamics. 

Undocking forces and moments are assumed negligible at present. 

2. 5. 2. 3 Separation Dynamics 

The nominal operations of the mechanisms for SRB/ET, Orbiter/ET, and 
Orbi ter/launch-aircraft separation do not induce any perceptible reaction 
forces or moments. Aerodynamic and mass properties changes will be updated 
for each configuration change, and propulsive systems activities will be 
simulated where appropriate (SRB separation rockets, Orbiter RCS maneuver 
following tank separation). We do not consider simulation of separation- 
system failures in this study. 

2. 5. 2. 4 Actuation-Mechanism Dynamics 

Reaction forces from actuation of the payload bay door, other Orbiter 
hatches, etc. are negligible. Control actuators {ME and OMS gimbals, 
aerosurfaces and body flap ) induce changes in body forces and moments by 
interaction with propulsion and aerodynamic simulations. 
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2. 5. 2. 5 Payload Deployment/ Retrieval Dynamics 

The PDRS (manipulator arms), Fig. 2-32 , may be used to assist in 
docking maneuvers, as well as in the handling of payloads. Reaction 
forces and moments on the Orbiter and payload/target will depend upon 
the Orbiter and payload masses and inertias, relative states and rates, 
the orientation of the various segments of the arms, and the forces and 
torques applied by each manipulator-arm actuator. These dynamics are 
inherently complex, and not amenable to simplification. Tests for 
undesired contact will also be required. 

2.5.3 Bending and Slosh Dynamics 

Body bending and fuel slosh dynamics will be modelled only during 
the ascent and entry phases, the entry implementation being much simplified. 

Body bending modes are excited by aerodynamics and thrust-vector-control 
inputs. Fuel s’", i modes are excited by inertial coupling with rigid-body 
motions in th r ( Mtcn and yaw planes. Module outputs include forces and 
momr-'its due to exchange of momentum between rigid-body dynamics and bending/ 
slosh modes, and contributions to inertial sensor outputs (euler angles, 
angular rates, and linear accelerations), varying with the sensor longitudinal 
position. 

Extensive offline precomputation will be used to generate a set of simple 
second-order equations in a set of generalized coordinates -- the "normal modes" 
of body bending and fuel slosh. Coefficients of these modal equations will be 
called from storage for each change in vehicle configuration -- SRB and ET 
separation — and will vary parametrically with propellant depletion. The 
modal equations will be integrated in real time; the outputs of the modal 
equations will then be multiplied by precomputed "sensitivity" (mode shape) 
functions to generate the perceived effects. 
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FIGURE 2-31 . ORBITER/DOCKING-TARGET PRECONTACT CONDITIONS. 





FIGURE 2-32 . EXAMPLE REACTION FORCES AND MOMENTS FROM PAYLOAD 
DEPLOYMENT. 
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2.5.4 Validation Methods and Data Sources 

Validation of dynamical simulations by comparison to an existing, 
previously-validated simulation is a very common approach. Indeed, when 
a full range of system complexities is included, hand-computation of check 
data Is not feasible, analytical solutions do nut exist, and comparison with 
another powerful simulation is the only available approach. 

Programs of adequate accuracy and versatility are currently available 
and in regular use at JSC (Refs. 28 and 29 ), both for single-body and 
multiple-body relative dynamics. Any of the common reference missions should 
serve as a suitable check case. Reference 23 identifies a number of other 
simulations covering various aspects of vehicle dynamics. Some care must be 
applied, in using any of these models as a source of reference data, that 

(a) it is itself adequately validated, and 

(b) is Independent of the simulation module 
validated. 

For translational EOM, method of independent validation which is suitable 
for desk calculation is to remove all perturbing forces, and verify that the 
simulation module generates the proper Kepler orbit for several sets of initial 
conditions. Then re-introduce perturbation terms (oblateness, drag, luni -solar 
forces, etc.) individually, and check the resultant effect against standard 
closed-form approximations (e. g., of the type given in Ref. 30 ). 

Simple check cases useful for partial validation of rotational EOM include 
free rotation about any principal axis. Free rotation about an axis other 
than a principal axis is complex in form, but one simple check is to ensure that 
angular momentum and rotational kinetic energy are both conserved. Forced 
rotational motion can be approximately validated by determining the 
angular-momentum chanqes resulting from torque pulses of short duration, applied 
in a variety of body-axis orientations. 
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Appropriate force and torque pulses at appropriate body-axis locations 
can be used to verify proper handling of inputs from mechanical -system 
modules, in advance of integrated validation of mechanical -system and 
vehicle-dynamics modules. On-line graphics capability would be desirable 
for verifying proper operation of the computations and logic involved in 
detecting undesired contact between the Orbiter and other bodies involved 
in multiple-body dynamical simulation. Reference 31 describes a JSC 
software package of potential utility for this application. 
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